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(57) ABSTRACT 

Methods of handling messages at an interface in a commu- 
nication system include the steps of receiving a message 
having an information element indicating the message's 
type, determining whether a frequency of receipt of mes- 
sages of a predetermined type exceeds a threshold, handling 
the message in a normal way if the frequency does not 
exceed the threshold, and discarding the message if the 
frequency exceeds the threshold and the message is of the 
predetermined type. Such methods are useful in avoiding 
overloads after re-starts of serving GPRS support nodes or 
base station systems in packet-switched communication 
systems. 
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OVERLOAD PROTECTION IN PACKET 
COMMUNICATION NETWORKS 

[0001] This application claims priority to U.S. Provisional 
Patent Application No. 60/229,323 that was filed on Sep. 1, 
2000, and that is incorporated here by reference. 

BACKGROUND 

[0002] This invention relates to methods and apparatus for 
telecommunication and in particular to packet-switched (PS) 
communication systems that are adapted to handle re-starts 
and re-allocation of system nodes. 

[0003] In a packet data communication system, informa- 
tion is exchanged as packets of digital data, or datagrams. 
Each data packet includes address information that enables 
the system to direct each packet on its own way through the 
system from a sender to a receiver. Thus, a packet data 
communication system does not maintain a continuous 
connection between a sender and a receiver. Packet data 
communication systems are sometimes called "connection- 
less" and packet-switched systems, distinguishing them 
from traditional telephony systems in which continuous 
connections are established between senders and receivers. 
Thus, traditional telephony systems are sometimes called 
"connection-oriented" and circuit-switched (CS) systems. 

[0004] General packet radio service (GPRS) is a packet- 
switched communication system that is standardized by the 
European Telecommunications Standards Institute (ETSI) 
and the Third Generation Partnership Project (3GPP). See 
for example "Digital Cellular Telecommunications System 
(Phase 2+) (GSM); General Packet Radio Service (GPRS); 
Service description; Stage 2", 3GPP TS 03.60 ver. 7.6.0 
Release 1998; and "General Packet Radio Service (GPRS); 
Service Description; Stage 2", 3GPP TS 23.060 ver. 3.3.0 
Release 1999 (Apr. 2000). GPRS is also described in H. 
Granbohm et al, "GPRS— General Packet Radio Service", 
Ericsson Review No. 2, pp. 82-88 (1999) and in L. Ekeroth 
et al., "GPRS Support Nodes", Ericsson Review No. 3, pp. 
156-169 (2000). 

[0005] GPRS operates with circuit-switched, cellular 
mobile telephone systems such as the Global System for 
Mobile (GSM) system, also standardized by ETSI and 
3GPP, and the U.S. time division multiple access (TDMA) 
cellular system defined by the TIA/EIA-136 standard pro- 
mulgated by the Telecommunications Industry Association 
(TIA) and Electronic Industries Association (EIA). By add- 
ing GPRS functionality to GSM and TDMA public land 
mobile networks (PLMNs), network operators can give their 
subscribers resource-efficient access to external Internet 
protocol -based (IP-based) packet data networks (PDNs) like 
the Internet. 

[0006] As depicted in FIG. 1, a GSM-style PLMN 
includes a number of interconnected network nodes, in 
particular, a mobile switching center/visitor location register 
(MSC/VLR), a home location register (HLR), and base 
station systems (BSS). The BSS handles radio communica- 
tion with subscribers' mobile stations (MSs) via an air 
interface Um. The HLR is a database of information about 
the subscribers that is accessed by the MSC/VLR via a 
D-interface and that is accessed by a serving GPRS support 
node (SGSN) via a Gr-interface. The MSC/VLR routes 
circuit-switched calls to and from the MSs, communicating 



with the BSS over an A-interface. It will be appreciated that 
these nodes are typical of a circuit-switched network such as 
a PLMN, whether GSM or not. Data transfer and signaling 
interfaces are indicated in FIG. 1 by solid lines and signal- 
ing interfaces are indicated by dashed lines. 

[0007] Packet data services and GPRS add nodes in a 
packet-switched portion of the communication network for 
handling packet data traffic; these nodes interwork with the 
circuit-switched portion of the communication system 
depicted in FIG. 1. For example, an SGSN is connected to 
the BSS via a Gb-interface and resides at the same hierar- 
chical level in the network as the MSC/VLR. A gateway 
GPRS support node (GGSN) is the interconnection point to 
a packet data network via a Gi-interface and is connected to 
the SGSN via a Gn-interface (which may be an IP back- 
bone). User data to the Internet, directed for example, from 
a terminal equipment (TE) connected to a mobile terminal 
(MT), is sent encapsulated over the IP backbone. In FIG. 1, 
R is a reference point between a non-ISDN compatible TE 
and an MT. In this application, the end-user's equipment is 
called a mobile station (MS) whether it is a combination of 
a phone (MI) and a device such as a computer (TE) or just 
a phone. 

[0008] The SGSN and GGSN can be combined into one 
physical node and deployed at a central point in the network, 
or a network may include several GGSNs and SGSNs as 
shown. Packet data streams and short text messages are 
handled in FIG. 1 by a Short Message Service — Gateway 
MSC (SMS-GMSC) and an SMS— Interworking MSC 
(SMS-IWMSC) that communicate with the HLR via a 
C-interface and with the MSC/VLR via an E-interface. As 
seen in FIG. 1, the SMS-GMSC and SMS-IWMSC 
exchange short messages with a short message switching 
center (SM-SC), and the SMS-GMSC communicates with 
the SGSN via a Gd-interface. It will be appreciated that the 
nodes depicted in FIG. 1 are typical of a packet-switched 
network, whether a GPRS network or not. It will also be 
appreciated that some networks physically split node(s) into 
control plane node(s) and user plane node(s) in order to 
enable independent scalability of signaling traffic and data 
traffic, among other reasons. 

[0009] Most of the interfaces depicted in FIG. 1, and in 
particular the Gs- and A-interfaces, exchange messages with 
the help of the Signaling System Number 7 (SS7) that is 
standardized by ETSI and the American National Standards 
Institute (ANSI), among others. SS7 in GSM and GPRS uses 
a message transfer part (MTP) protocol to deliver messages 
and a signaling connection control part (SCCP) protocol for 
extended addressing. The SCCP protocol provides for each 
message to have an SCCP header that has a sub-system 
number for telling the node receiving the message which 
application should have the message. An SGSN, for 
example, typically has different sub-system numbers for 
communication with the HLR and with the MSC/VLR. An 
MSC usually derives the node type of a communicating peer 
node based on the sub-system number that may be stored in 
a database or included in an earlier message. 

[0010] In a GPRS network, packet data channels (PDCHs) 
are mapped onto respective timeslots, thereby utilizing the 
same physical channel structure as ordinary circuit -switched 
GSM/TDMA channels. All radio resources are managed 
from a base station controller (BSC) in the BSS, which also 
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includes Base Transceiver Stations (BTS); the pool of physi- 
cal channels for a given cell can be used as either circuit- 
switched channels or packet-data channels. By packet mul- 
tiplexing, the allocated PDCHs can be shared by every 
GPRS user in the cell, and the number of PDCHs in a cell 
can be fixed or dynamically allocated to meet fluctuating 
traffic demands. To support efficient multiplexing of packet 
traffic to and from mobile stations, or mobile terminals 
(MTs), packet data traffic channels (PDTCHs), packet asso- 
ciated control channels (PACCHs), and packet data common 
control channels (PDCCHs) are specified for the air inter- 
face Um, although PDCCHs are not always used. 

[0011] As noted above, an SGSN serves every GPRS 
subscriber that is physically located within the SGSN's 
service area. To a large extent, the SGSN does for packet- 
switched service what the MSC/VLR does for circuit- 
switched service. The mobility management functions for 
GPRS terminals that are performed by an SGSN include 
attach/detach, user authentication, ciphering, location man- 
agement, and so on, and an SGSN supports combined 
mobility management for at least some mobile terminals by 
interworking with the MSC/VLR. An SGSN also manages 
the logical link to mobile terminals that carries user packet 
traffic, SMS traffic, and layer-3 signaling between the net- 
work and the GPRS terminals. An SGSN also routes and 
transfers packets between mobile terminals and the GGSN; 
handles packet data protocol (PDP) contexts (the PDP 
context defines important parameters, such as the access 
point name, quality of service, the GGSN to be used, and so 
on, for connection to the external packet data network); 
interworks with the radio resource management in the BSS; 
and generates charging data. 

[0012] As noted above, the GGSN accommodates the 
interface to external IP-based networks. Access-server func- 
tionality in the GGSN is defined according to standards from 
the Internet Engineering Task Force (IETF). The GGSN 
functions as a border gateway between the PLMN and 
external networks, sets up communication with external 
packet data networks, authenticates users to external packet 
networks, routes and tunnels packets to and from the SGSN, 
and generates charging data. 

[0013] The MSC/VLR also supports integrated mobility 
management for mobile terminals. GPRS attach and PDP- 
context activation must be executed in order for GPRS users 
to connect to external packet data networks. The mobile 
terminal makes itself known to the network by means of 
GPRS attach, which corresponds to IMSI attach used for 
circuit-switched traffic. Once the terminal is attached to the 
network, the network knows its location and capabilities. 
For some mobile terminals, circuit-switched IMSI attach 
and packet-switched GPRS attach can be performed at the 
same time. 

[0014] GPRS attach is depicted by FIG. 2. In step 1, the 
mobile terminal requests that it be attached to the network. 
The terminars request, which is sent to the SGSN, includes 
parameters that indicate its multi-timeslot capabilities, the 
ciphering algorithms it supports, whether it wants to attach 
to a packet-switched service or to both packet- and circuit- 
switched services, etc. In step 2, authentication is made 
between the terminal and SGSN, which may fetch relevant 
data from the HLR. In step 3, subscriber data from the HLR 



is inserted into the SGSN; and in step 4, information is 
passed to the terminal that indicates the terminal is attached 
to the network. 

[0015] Before the mobile terminal can communicate with 
an external PDN (e.g., an IP network), a PDP context must 
be activated. The PDP context includes parameters that 
describe the characteristics of the connection to the external 
PDN, e.g., the address allocated to the MS, access point 
name (APN), quality of service (QoS), and so on. PDP 
contexts may be primary or secondary, in which a secondary 
PDP context uses the same MS IP address and is connected 
towards the same APN (i.e., external net) as its respective 
primary PDP context. A composite PDP context contains one 
primary and zero or more secondary PDP contexts. 

[0016] PDP-context activation is depicted in FIG. 3. In 
step 1, the mobile terminal requests PDP-context activation. 
In step 2, the SGSN validates the request based on subscrip- 
tion information received from the HLR during GPRS 
attach. In step 3, the APN is sent to a domain name server 
(DNS) from the SGSN to find the IP address of the relevant 
GGSN. In step 4, a logical connection is created between the 
SGSN and the GGSN (i.e., a GPRS Tunneling Protocol 
(GTP) tunnel is formed). In step 5, the GGSN assigns a 
dynamic IP address to the mobile terminal, if required, from 
the range of IP addresses allocated to the PLMN or exter- 
nally, from a Remote Authentication Dial-In User Service 
(RADIUS) server (a fixed IP address from the HLR could 
also be used). A RADIUS client is included in the GGSN to 
support Password Authentication Protocol (PAP) and Chal- 
lenge Handshake Authentication Protocol (CHAP) authen- 
tication to external networks with RADIUS servers. After an 
acknowledgment of the PDP context activation is returned to 
the MS (step 6), communication between the user and the 
external PDN (e.g., an Internet Service Provider (ISP) 
network or a corporate network) can commence (step 7). 

[0017] In GPRS, establishing a PDP context signifies 
establishing a communication session in an MS, the radio 
network, an SGSN, and a GGSN. In addition, GPRS 
includes a "heartbeat" mechanism implemented by Echo 
Request and Echo Response messages that every node/entity 
sends to all of its communication peers over the Gn- and 
Gp -interfaces, and if a reply is received and a re-start 
counter of the peer is different from the previously received 
counter value, the peer is considered re-started. 

SUMMARY 

[0018] Applicants describe methods of handling messages 
at an interface in a communication system that include 
receiving messages having an information elements indicat- 
ing message type, determining whether a frequency or 
volume of receipt of messages of a predetermined type 
exceeds a threshold, handling the messages in a normal way 
if the frequency does not exceed the threshold, and discard- 
ing the messages if the frequency exceeds the threshold and 
the messages are of the predetermined type. Such methods 
are useful in avoiding overloads after re-starts of serving 
GPRS support nodes or base station systems in packet- 
switched communication systems. 

[0019] This method may be carried out by an SGSN or a 
BSS after a re-start of the SGSN or BSS. Also, the message 
type may be a local temporary logical link identity, and 
messages of types other than the predetermined type are 
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handled in the normal way even when the frequency exceeds 
the threshold. The method may further include the step of 
determining whether a frequency of receipt of messages of 
a plurality of types exceeds a second threshold; if it does, the 
other steps of the method are carried out, but if it does not, 
a message is handled in the normal way. 

[0020] According to another aspect, Applicants provide a 
method of handling messages at an interface in a commu- 
nication system that includes the steps of receiving an uplink 
message and reading an information element in a header of 
the received message; accessing a table based on the read 
information element to determine a status of the read infor- 
mation element as either already known or unknown; and 
based on the table access, handling the message in a normal 
way if the information element is known. If the information 
element is unknown, the following steps are carried out: 
updating a frequency of receipt of unknown read informa- 
tion elements; comparing the updated frequency to a thresh- 
old; and if the updated frequency is less than the threshold, 
handling the message in the normal way. If the updated 
frequency is not less than the threshold, the following steps 
are carried out: determining whether the read information 
element is of a predetermined type; if the read information 
element is not of the predetermined type, handling the 
message in the normal way, and if the read information 
element is of the predetermined type, discarding the mes- 
sage. 

[0021] This method may be carried out in an SGSN or a 
BSS after a re-start of the SGSN or BSS, and the information 
element may be a temporary logical link identity. Also, the 
threshold may be based on processing resources available in 
the SGSN for handling messages, and the processing 
resources may include an amount of free memory left to the 
SGSN and/or a load on a central processing unit of the 
SGSN. This method may further include the step of deter- 
mining whether the message includes a second information 
element that is encrypted, with this step being carried out if 
the updated frequency does not exceed the threshold and 
before handling the message in the normal way; if the 
second information element is not encrypted, the message is 
handled in the normal way, but if the second information 
element is encrypted, the message is discarded. 

[0022] This method may also include comparing, if the 
information element is not of the predetermined type, a 
frequency of receipt of messages having information ele- 
ments of another type to a second threshold, where if the 
second threshold is not exceeded, the message is handled in 
the normal way, but if the second threshold is exceeded, the 
message is discarded. Such a method may further include the 
step of determining whether the message includes a second 
information element that is encrypted, this step being carried 
out if the frequency does not exceed the second threshold 
and before handling the message in the normal way; if the 
second information element is not encrypted, the message is 
handled in the normal way, but if the second information 
element is encrypted, the message is discarded. 

[0023] The method may further include the step of deter- 
mining whether a frequency of receipt of messages of a 
plurality of types exceeds a second threshold; if the fre- 
quency exceeds the second threshold, the other steps of the 
method are carried out, but if the frequency does not exceed 
the second threshold, a message is handled in a normal way. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0024] The features, objects, and advantages of this inven- 
tion will be apparent from reading this description in con- 
junction with the drawings, in which: 

[0025] FIG. 1 depicts a combined packet-switched and 
circuit-switched communication network; 

[0026] FIG. 2 depicts a simplified GPRS attach in a 
packet-switched network; 

[0027] FIG. 3 depicts a simplified PDP context activation 
in a packet-switched network; 

[0028] FIG. 4 depicts the BSSGP protocol stack for 
payload in GPRS; 

[0029] FIG. 5 depicts the BSSGP protocol stack for 
MS-SGSN signaling in GPRS; and 

[0030] FIGS. 6A, 6B, 6C are flowcharts of methods in 
accordance with aspects of this invention. 

DETAILED DESCRIPTION 

[0031] This description is given in terms of GPRS for 
convenience only, and it will be appreciated that the prin- 
ciples of the invention can be applied in other packet- 
switched networks having suitable characteristics. 

[0032] If an SGSN has to be re-started for some reason, 
e.g., due to hardware or software problems, the SGSN loses 
all information regarding its attached MSs (i.e., state, 
encryption triplets, etc.). MSs attached to a re-started SGSN 
are not typically notified about the re-start, so in the course 
of re-starting (especially during a busy time of day), the 
SGSN receives communications from a large portion of the 
(formerly attached) MSs. The volume of communications 
can easily overwhelm the message processing capabilities of 
the SGSN, leading to another re-start (cyclic re-start) and a 
possible vicious circle since the MSs still will be unaware 
that the SGSN has re-started. 

[0033] When the Gb-interface between the BSS and 
SGSN is restored, all types of MS-originated communica- 
tions arrive at the SGSN. These communications include 
GPRS MM and session management (GMM) messages such 
as attach-request messages, periodic Routing Area messages 
(the MS has not changed RA), Routing Area update mes- 
sages (the MS has entered a new RA), and other MM 
messages. These communications also include MS-origi- 
nated SMS messages, MS-originated payloads, and signal- 
ing messages, e.g., parameter negotiation (XID) and other 
messages according to logical link control (LLC) and sub- 
network dependent convergence (SNDC) protocols. FIGS. 
4 and 5 show the BSSGP protocol in its correct environment 
within the GPRS. 

[0034] FIG. 4 shows the protocol stacks used for payload 
(e.g., IP packets) and FIG. 5 shows the protocol stacks 
involved in MS-SGSN signaling, e.g., sending SMS mes- 
sages. The organizations of these figures will be recognized 
as conforming to the OSI model. As can be seen from FIGS. 
4 and 5, the Gb-interface between the SGSN and BSS 
employs a Llbis protocol for messages on the lowest layer, 
layer 1 (LI); a network service protocol for messages on 
layer 2 (L2); and a BSS GPRS protocol (BSSGP) for 
messages on layer 3 (L3). Other interfaces and layers are 
shown in FIGS. 4 and 5 for completeness, and include a 
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radio frequency (RF) protocol, medium access control 
(MAC), and radio link control (RLC) protocols for LI, L2, 
and L3, respectively, of the air interface Urn, which may be 
a GSM interface, and LI, L2, and IP protocols for the 
Gn-interface between an SGSN and a GGSN. It can be seen 
from the figures that these entities communicate on higher 
layers according to appropriate protocols, such as the user 
datagram protocol and transmission control protocol (UDP/ 
TCP) and the IP and X.25 protocols. 

[0035] When a message from a not-attached MS (even 
from an MS which still believes it is attached) is received by 
the SGSN (i.e., the BSSGP layer), the message must be 
treated as an attach-request message, at least until it is 
determined that the message was something else. If it is 
determined that the message was something else, a "detach 
request with request to re-attach" message is sent from the 
SGSN to the MS. After a re-start, processing power in the 
layers higher than the BSSGP layer (L3) must be used to 
determine the types of messages actually sent by the MSs. 

[0036] Since the typical approach requires so much pro- 
cessing power that it is unacceptable when the volume of 
"unknown" MSs is high, Applicants have recognized that it 
is possible to use the fact that the BSSGP layer is the lowest 
layer of the Gb-interface in which an individual MS is 
identified to reduce the necessary processing power and 
facilitate SGSN re-starts. 

[0037] "Digital Cellular Telecommunications System 
(Phase 2+) (GSM); General Packet Radio Service (GPRS); 
Base Station System (BSS) — Serving GPRS Support Node 
(SGSN); BSS GPRS Protocol (BSSGP)", 3GPP TS 08.18 
ver. 6.7.1 Release 1997 (May 2000) specifies a temporary 
logical link identity (TLU) that identifies a specific MS. 
According to section 10.2.1 of the BSSGP specification, the 
TLLI is a mandatory information element in a UNITDATA 
protocol data unit (PDU) that is sent according to the BSSGP 
in the uplink (UL), i.e., from the BSS to the SGSN. TLLIs 
can have four types: 1) local TLLI, 2) foreign TLLI, 3) 
random TLLI, and 4) auxiliary TLLI, as specified by "Digi- 
tal Cellular Telecommunications System (Phase 2+) (GSM); 
Numbering, addressing and identification", 3GPP TS 03.03 
ver. 6.5.0 Release 1997 (March 2000). 

[0038] The usage of the four types of TLLI is specified in 
section 4.7.1.4 of "Digital Cellular Telecommunications 
System (Phase 2+) (GSM); Mobile Radio Interface Layer 3 
Specification", 3GPP TS 04.08 ver. 6.10.0 (6.a.0) Release 
1997 (April 2000). A local TLU is used by the MS in all UL 
PDUs after a successful GPRS attach, including "periodic 
Routing Area update" messages. A foreign TLLI is used by 
the MS during GPRS attach and when the MS enters a new 
Routing Area. A random TLLI is used when the MS does not 
have a TLLI from a previous attach (so-called IMSI attach). 
An auxiliary TLLI might be used by the BSSGP layer, 
although it is used by the GMM layer only when the MS 
requests an anonymous PDP context as specified in section 
6.1.3.4.1 of the mobile radio interface layer 3 specification. 
It can be noted from the specifications cited above that 
anonymous PDP contexts have been removed from Release 
1999 of GPRS, and so auxiliary TLLIs need not be further 
discussed here. 

[0039] In accordance with one aspect of Applicants* 
invention, the SGSN is programmed or otherwise configured 
such that during re-start, the BSSGP layer in the SGSN 



accepts uplink UNITDATA PDUs having either foreign or 
random TLLIs (i.e., new GPRS attaches) and silently dis- 
cards uplink UNITDATA PDUs having local TLLIs (i.e., all 
other messages, such as periodic Routing Area messages, 
payload, and SMS). A (formerly attached) MS that has sent 
a UNITDATA PDU having a local TLLI will retransmit it, 
perhaps a number of times, but eventually the MS will quit 
and perform a new GPRS attach with a foreign TLLI. 

[0040] It will be appreciated that it is not necessary for an 
SGSN to be configured such that the SGSN always discards 
uplink UNITDATA PDUs having local TLLIs. Always dis- 
carding such PDUs simplifies the operation of the SGSN to 
some extent. On the other hand, always throwing away 
PDUs having local TLLIs increases the time needed to 
re-attach all formerly attached MSs, and MSs that are 
actively interchanging payloads when the SGSN re-starts 
need longer times to determine that the problem is the GPRS 
core network, not a "slow Internet". In other words, it will 
take longer for an MS to detect that it has been "thrown out" 
of an SGSN. For a connection between an MS terminal 
equipment (TE) and an external PDN that uses TCP, the MS 
TE reports to its application that "I am giving up" when the 
TCP layer at the MS side quits re-sending an uplink TCP 
packet. It is then impossible for the MS end-user (e.g., a 
human) to judge whether the problem was in the GPRS core 
network or in the PDN, so the end-user would then try to 
attach again manually. 

[0041] Rather than always discarding PDUs having local 
TLLIs after a re-start, the SGSN can be more selective, 
determining when it should discard such PDUs, and thus 
provide faster, automatic re-attachment and re-activation of 
MSs, and SGSN protection against overloads and assurance 
of acceptable levels of in-service performance (uptime). In 
other words, the SGSN can be configured to have at least 
two re-start states in the BSSGP layer in the SGSN, a first 
state in which PDUs having local TLLIs are not discarded 
and a second state in which they are. To determine which 
state the SGSN should be in, the BSSGP layer preferably 
monitors the reception frequency or volume of messages 
having "unknown TLLI (of all types)". When this frequency 
or volume is greater than a threshold level that reflects the 
processing capabilities of the SGSN, the BSSGP layer enters 
the second re-start state and discards "unknown MSs with 
local TLLI". When the frequency or volume of unknown 
TLLIs is less than the threshold level, the BSSGP layer 
enters the first state, normally handling and accepting 
"unknown MSs with Local TLLI". It will be understood that 
the terms "frequency" and "volume" are used interchange- 
ably in this application because these parameters are mutu- 
ally related, and it is not significant which parameter is 
monitored. 

[0042] FIGS. 6A, 6B, 6C are flowcharts of methods in 
accordance with aspects of Applicants' invention that are 
implemented in a SGSN in the communication network. 
Referring to FIG. 6A in step 602, the BSSGP layer (L3) in 
the SGSN receives an uplink UNITDATA PDU from a lower 
layer (L2 or LI) and reads the received TLU in the header 
of the received PDU. In step 604, the SGSN uses the 
received TLLI as a key, address, or other indicator to access 
a table or other database that indicates the status of the 
received TLLI as either already known (e.g., from an already 
received PDU) or unknown to the SGSN. Based on the table 
look-up (step 606), the SGSN handles the received PDU in 
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the normal way if the TLLI is known (step 608). Otherwise, 
the SGSN updates a counter or other suitable mechanism 
that indicates the frequency or volume of unknown received 
TLLIs (step 610) and then compares the updated frequency 
or volume to a threshold that is based on the processing 
power available for handling PDUs having unknown TLLIs 
(step 612). 

[0043] If processing resources are still available, e.g., if 
the updated frequency or volume is less than the threshold, 
the PDU is handled in the normal way, with the SGSN 
sending an appropriate response to the PDU (step 614). On 
the other hand, if processing resources are not available, the 
received TLLI is examined to determine whether it is a local 
TLLI (step 616). If it is not local, i.e., if it is either foreign 
or random (the PDU is a new GPRS attach), the PDU is 
handled in the normal way, but if it is local, the received 
PDU is discarded without sending a response (step 618). 

[0044] It will be understood that the method depicted in 
FIG. 6A relates availability of SGSN or similar processing 
resources to the threshold since such resources can be scarce 
during re-start, and possibly during other circumstances, 
such as a BSS re-start (after which the frequency of uplink 
PDUs having foreign TLLIs may be high since MSs detect 
the BSS re-start and have to re-attach), it may be useful to 
discard PDUs having particular types of TLLIs. Processing 
resources can be measured in many ways, including for 
example the amount of free memory left to the SGSN and/or 
the load on the SGSN's central processing unit (CPU). It 
should also be understood that it can be useful to discard or 
change the handling of PDUs having foreign/random TLLIs, 
and a method for doing so is depicted in FIG. 6B. The 
methods depicted in FIGS. 6 A, 6B have many common 
steps, which are indicated by common reference numerals 
and need not be described again. 

[0045] In FIG. 6B, however, another threshold decision 
step 620 is carried out for the NO result of the decision at 
step 616. If a TLLI is not local, i.e., if it is either foreign or 
random (the PDU is a new GPRS attach or Routing Area 
update), the SGSN compares an updated frequency or vol- 
ume of received unknown random/foreign TLLI to a thresh- 
old that may also be based on the processing power available 
for handling PDUs having unknown TLLIs (step 620). This 
frequency or volume of received unknown random/foreign 
TLLI parameter can be maintained and updated in a manner 
substantially similar to the manner of maintaining the fre- 
quency or volume of received unknown TLLI that is 
described in connection with FIG. 6A. If the threshold is not 
exceeded, the PDU is handled in the normal (step 614), but 
if the threshold is exceeded, the received PDU is discarded 
without sending a response (step 618). 

[0046] Applicants have also found that operation of an 
SGSN can be assisted even when the SGSN is not over- 
loaded. For example, in steps 608, 614, if the SGSN deter- 
mines that the received PDU contains an encrypted, or 
enciphered, service data unit (SDU), the SGSN replies with 
a detach-with-request-to-re-attach message that is unen- 
crypted (i.e., in plaintext). The SGSN is not able to decrypt 
the received PDU due to unavailability of vital state infor- 
mation and is also not able to encrypt its reply for the same 
reason. Nevertheless, section 4.7.1.2 of the Mobile Radio 
Interface Layer 3 Specification requires that such reply 
messages must be encrypted. As a result, each MS decides 



on its own whether to accept an unencrypted detach-with- 
request-to-re-attach message. If the MS rigorously adheres 
to security standards, the MS discards the SGSN's message, 
and thus continues to believe that it is attached to the SGSN 
when it is not. Stated another way, the SGSN tries to help the 
MS re-attach more quickly, but the MS refuses the help. 
Rather than permit this to occur, the SGSN advantageously 
discards such an uplink UNITDATA PDU. 

[0047] It will be understood that the knowledge of whether 
a PDU is encrypted or not can be located at the BSSGP layer, 
in particular in the BSSGP SDU. All that is needed is for the 
BSSGP layer to understand the protocol layout of the layer 
above it, i.e., how to read the LLC header. This is easy to 
implement, although it is an unconventional configuration. 

[0048] Accordingly, FIG. 6C shows the method depicted 
in FIG. 6A with another decision step 622 that is carried out 
for the NO result of the decision at step 612. If an unknown 
TLLI is local, i.e., if it is neither foreign nor random (the 
PDU is not a new GPRS attach nor Routing Area update), 
the SGSN determines whether the SDU associated with the 
received unknown local TLLI is encrypted. If the determi- 
nation is No, the PDU is handled in the usual way (step 614), 
but if the determination is Yes, the received PDU is dis- 
carded without sending a response (step 618). 

[0049] It will be understood that the decision step 622 can 
also be added to the method depicted in FIG. 6B. 

[0050] Applicants' invention enables an SGSN to be pro- 
tected from overload due to large message volume during 
re-start by arranging for only new attaches to be taken care 
of in the SGSN. Filtering away other types of MS-originated 
traffic with low usage of processing power avoids another 
re-start. 

[0051] It will be appreciated that Applicants' invention is 
not limited to systems operating according to the specific 
communication standards or releases of the standards 
described above. Although references were made to Release 
97 of the GPRS standards, Applicants* invention is also 
applicable to methods and apparatus operating according to 
other releases in which a BSSGP layer or the like exists at 
a Gb-interface or the like. In particular, although this appli- 
cation refers to TLLIs, it should be understood that the term 
"TLLI" is intended to encompass any data element or 
elements having the character of a temporary logical link 
identity that identifies a specific MS and that has the three 
main types discussed above. 

[0052] It will also be appreciated that Applicants* inven- 
tion may be used in a traditional circuit-switched network 
such as the circuit-switched portion of a UMTS, GSM, or 
similar network when packet bearers such as IP packets are 
used for circuit-switched sessions. Although such networks 
might not be considered traditional "circuit-switched net- 
works" to the extent that they handle packet bearers, this 
terminology will be understood in this application to mean 
simply networks that are typical of traditional circuit- 
switched networks but that have been updated in that they 
handle packet bearers. 

[0053] Applicants' invention is described above in con- 
nection with various embodiments that are intended to be 
illustrative, not restrictive. It is expected that those of 
ordinary skill in this art will modify these embodiments. The 
scope of Applicants' invention is defined by the following 
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claims, and all modifications that fall within the scopes of 
these claims are intended to included therein. 

What is claimed is: 

1. A method of handling messages at an interface in a 
communication system, comprising the steps of: 

a) receiving a message having an information element 
indicating the message's type; 

b) determining whether a frequency of receipt of mes- 
sages of a predetermined type exceeds a threshold; 

c) handling the message in a normal way if the frequency 
does not exceed the threshold; and 

d) discarding the message if the frequency exceeds the 
threshold and the message is of the predetermined type. 

2. The method of claim 1, wherein the method is carried 
out by a serving general packet radio service support node 
(SGSN) after the SGSN is re-started. 

3. The method of claim 2, wherein the information 
element is a local temporary logical link identity, and 
whereby messages of another type are handled in the normal 
way even when the frequency exceeds the threshold. 

4. The method of claim 1, wherein the method is carried 
out by a base station system (BSS) after the BSS is re- 
started. 

5. The method of claim 1, further comprising the step of 
determining whether a frequency of receipt of messages of 
a plurality of types exceeds a second threshold, wherein if 
the frequency exceeds the second threshold, steps b), c), and 
d) are carried out, and if the frequency does not exceed the 
second threshold, handling the message in the normal way. 

6. A method of handling messages at an interface in a 
communication system, comprising the steps of: 

a) receiving an uplink message and reading an informa- 
tion element in a header of the received message; 

b) accessing a table based on the read information element 
to determine a status of the read information element as 
either already known or unknown; 

c) based on the table access, handling the message in a 
normal way if the information element is known, and 
otherwise carrying out the following steps: 

d) updating a frequency of receipt of unknown read 
information elements; 

e) comparing the updated frequency to a threshold; 

f) if the updated frequency is less than the threshold, 
handling the message in the normal way, and otherwise 
carrying out the following steps: 

g) determining whether the read information element is of 
a predetermined type; 



h) if the read information element is not of the predeter- 
mined type, handling the message in the normal way, 
and 

i) if the read information element is of the predetermined 
type, discarding the message. 

7. The method of claim 6, wherein the method is carried 
out in a serving general packet radio service support node 
(SGSN) after the SGSN is re-started and the information 
element is a temporary logical link identity. 

8. The method of claim 6, wherein the method is carried 
out in a base station system (BSS) after the BSS is re-started 
and the information element is a temporary logical link 
identity. 

9. The method of claim 6, wherein the threshold is based 
on processing resources available in the SGSN for handling 
messages. 

10. The method of claim 9, wherein the processing 
resources comprise at least one of an amount of free memory 
left to the SGSN and a load on a central processing unit of 
the SGSN. 

11. The method of claim 6, further comprising the steps of 
determining whether the message includes a second infor- 
mation element that is encrypted, the determining step being 
carried out if the updated frequency does not exceed the 
threshold and before handling the message in the normal 
way, and if the second information element is, not encrypted, 
handling the message in the normal way, but if the second 
information element is encrypted, discarding the message. 

12. The method of claim 6, wherein if the information 
element is not of the predetermined type, a frequency of 
receipt of messages having information elements of another 
type is compared to a second threshold, and if the second 
threshold is not exceeded, the message is handled in the 
normal way, but if the second threshold is exceeded, the 
message is discarded. 

13. The method of claim 12, further comprising the steps 
of determining whether the message includes a second 
information element that is encrypted, the determining step 
being carried out if the frequency does not exceed the second 
threshold and before handling the message in the normal 
way, and if the second information element is not encrypted, 
handling the message in the normal way, but if the second 
information element is encrypted, discarding the message. 

14. The method of claim 6, further comprising the step of 
determining whether a frequency of receipt of messages of 
a plurality of types exceeds a second threshold, wherein if 
the frequency exceeds the second threshold, steps d)-i) are 
carried out, and if the frequency does not exceed the second 
threshold, handling the message in a normal way. 

* * * * * 
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